also "/eth/v1/validator/prepare_beacon_proposer" need to have gas limit included in api request as well

also "/eth/v1/validator/prepare_beacon_proposer" need to have gas limit included in api request as well

Yes we'll need to bump the version as well.

That said, the beacon node does obtain this information in /eth/v1/validator/register_validator. Although it isn't a perfect solution by any means the beacon node could obtain the gas limit from here until we have a v2 of prepare_beacon_proposer in place.

That said, the beacon node does obtain this information in /eth/v1/validator/register_validator. Although it isn't a perfect solution by any means the beacon node could obtain the gas limit from here until we have a v2 of prepare_beacon_proposer in place.

maybe a good opportunity to consolidate those apis as suggested in ethereum/beacon-APIs#435

That said, the beacon node does obtain this information in /eth/v1/validator/register_validator. Although it isn't a perfect solution by any means the beacon node could obtain the gas limit from here until we have a v2 of prepare_beacon_proposer in place.

maybe a good opportunity to consolidate those apis as suggested in ethereum/beacon-APIs#435

If the consensus nodes want to go along with the suggestion at ethereum/beacon-APIs#435 (comment) that would certainly simplify things. The edge case of the beacon node not knowing the validator registrations directly after a restart is, though, real so we'd need to consider how to handle this.

If the consensus nodes want to go along with the suggestion at ethereum/beacon-APIs#435 (comment) that would certainly simplify things. The edge case of the beacon node not knowing the validator registrations directly after a restart is, though, real so we'd need to consider how to handle this.

Let's continue that discussion on the beacon-api issue

what is the result of the Beacon API discussion? Can we close this PR or is the change proposed here is yet under active discussion?

what is the result of the Beacon API discussion? Can we close this PR or is the change proposed here is yet under active discussion?

the beacon api discussion is kinda separate to this, so irrespective of the outcome there we should still think about having the CL pass the gas limit to EL via payload attributes instead of having a separate CLI flag on the EL client to configure this

imo the configuration should be done in the validator client to allow different configuration per pubkey, because the EL client doesn't have any context about connected validators and users are already used to this, we do this for the fee recipient for example

for gloas, it's important to revisit this topic as a CL client can "act as a builder" but to do that it needs to be able to adjust the gas limit per payload/slot based on the proposer preferences received over p2p, a static gas limit config via CLI flag will not work here